Amazon Auroraではt系インスタンスクラスタイプを使用すると停止時にローカルストレージ内のログが削除される件

大事なログや分析に使いたいログはCloudWatch Logsに流そう
#Amazon Aurora
#Amazon RDS
#AWS
のんピ
2025.01.07
 Aurora DBクラスターを停止→起動するとログが削除されたんだがこんにちは、のんピ(@non____97)です。
皆さんはAurora DBクラスターを停止→起動するとログが削除された経験はありますか? 私はあります。
CloudWatch LogsにDBのログを流すとそれなりに料金がかかります。特にlog_statementであればall、mod、pgaudit.logであればall、read、writeにすると大量のログが流れがちです。
Aurora PostgreSQL DB クラスターのクエリログ記録をオンにする - Amazon Aurora
pgAudit 拡張機能のセットアップ - Amazon Aurora
そのため、コスト削減のために開発環境についてはCloudWatch Logsへログ出力を行っていない場合もあるでしょう。
ただし、以下記事で紹介されているようにAurora DBクラスターを一時停止し、その後起動すると一時停止以前のログを閲覧することができないことが紹介されています。
https://dev.classmethod.jp/articles/tsnote-aurora-mysql-stopped-instance-error-log/
そのため、一時停止前のログを確認したい場合はCloudWatch Logsへのログ出力が必須なように思えます。
本当にそうでしょうか。
実際に確認してみます。
 いきなりまとめAurora MySQLの場合t系インスタンスクラスタイプ以外は以下ログについてローカルストレージ上で永続的に保持される
エラーログ
一般ログ
スロークエリログ
監査ログ

Aurora PostgreSQLでも同様の条件でpostgres.logを保持する
検証した限り、ログが削除されるシチュエーションは以下
t系のインスタンスクラスタイプを使用しており、停止→起動を行った場合
t系のインスタンスクラスタイプからr系のインスタンスクラスタイプに変更した場合
r系のインスタンスクラスタイプからt系のインスタンスクラスタイプに変更した場合
t系のインスタンスクラスタイプからAurora Serverless v2に変更した場合

検証した限り、以下のシチュエーションではログは保持される
r系のインスタンスクラスにて、サイズを変更する場合
r系のインスタンスクラスから別のr系のインスタンスクラスに変更する場合
再起動をする場合
再起動はt系であっても保持される

フェイルオーバーする場合

いずれのインスタンスクラスタイプでも一時停止中はログを表示できない
以下に当てはまる場合はCloudWatch Logsにログ出力をすることが推奨
t系のインスタンスクラスタイプを使用する
ログを長期間保持したい
ログに対して分析を行いたい
ログファイルを都度ダウンロードするのが面倒

RDSでは一時停止しても停止前のログが保持される
 ドキュメントを見るAWS公式ドキュメントを確認してみます。
Aurora MySQLのドキュメントには以下の記載がありました。
Aurora MySQL 用の一時ストレージの制限
Aurora MySQL は、Aurora ストレージサブシステムにテーブルとインデックスを格納します。Aurora MySQL は、非永続的な一時ファイルや非 InnoDB 一時テーブル用に、別個の一時ストレージまたはローカルストレージを使用します。ローカルストレージには、クエリ処理中の大きなデータセットのソートや、インデックスの作成オペレーションなどの目的に使用するファイルも含まれます。InnoDB 一時テーブルは含まれません。
Aurora MySQL バージョン 3 の一時テーブルの詳細については、「Aurora MySQL バージョン 3 での新しい一時テーブルの動作」を参照してください。バージョン 2 の一時テーブルの詳細については、「Aurora MySQL バージョン 2 での一時テーブルスペースの動作」を参照してください。
これらのボリュームのデータと一時ファイルは、DB インスタンスの起動時と停止時、およびホストの交換時に失われます。
これらのローカルストレージボリュームは、Amazon Elastic Block Store (EBS) によってバックアップされ、より大きな DB インスタンスクラスを使用することで拡張できます。ストレージの詳細については、「Amazon Aurora ストレージ」を参照してください。
ローカルストレージは、LOAD DATA FROM S3 や LOAD XML FROM S3 を使用して Amazon S3 からデータをインポートする場合や、SELECT INTO OUTFILE S3 を使用して S3 にデータをエクスポートする場合にも使用します。S3 からのインポートと S3 へのエクスポートの詳細については、以下を参照してください。
Amazon S3 バケットのテキストファイルから Amazon Aurora MySQL DB クラスターへのデータのロード
Amazon Aurora MySQL DB クラスターから Amazon S3 バケット内のテキストファイルへのデータの保存
Aurora MySQL は、ほとんどの Aurora MySQL DB インスタンスクラス (db.t2、db.t3、db.t4g などのバーストパフォーマンスインスタンスクラスタイプは除く) のエラーログ、一般ログ、スロークエリログ、監査ログに別個の永続ストレージを使用します。このボリュームのデータは、DB インスタンスの起動時や停止時、ホストの交換時に保持されます。
また、この永続的ストレージボリュームは Amazon EBS-backed であり、DB インスタンスクラスに応じた固定サイズを持ちます。より大きな DB インスタンスクラスを使用して拡張することはできません。
Amazon Aurora MySQL のパフォーマンスとスケーリングの管理 - Amazon Aurora
ポイントは以下です。
以下データはローカルストレージに保存される
非永続的な一時ファイル
非InnnoDB一時テーブル
クエリ処理中の大きなデータセットのソートに使用するファイル
インデックスの作成オペレーションに使用するファイル

ローカルストレージに保存されているデータは以下のタイミングで削除される
DBインスタンスの起動時
DBインスタンスの停止時
ホストの交換時

ただし、例外としてt系インスタンスクラスタイプ以外は以下ログについてローカルストレージ上で永続的に保持される
エラーログ
一般ログ
スロークエリログ
監査ログ

要するにインスタンスクラスタイプによってはログを永続的に保持するようです。
先ほどの記事もスクリーンショットを確認するとdb.t3.mediumとt系のインスタンスクラスタイプを使用していました。そのため、r系のインスタンスクラスタイプを使用していれば停止→起動でログがロストしてしまうということはなさそうですね。
なお、ログがローカルストレージ内で永続化しているとはいえrds.log_retention_periodで指定した時間より古いログは削除されます。設定の上限は7日(10,080分)です。長期間ログを保持したい場合や、インスタンスの入れ替えが発生した場合でもログを保持したい場合はCloudWatch Logsに流しましょう。
Setting the log retention period
The rds.log_retention_period parameter specifies how long your RDS for PostgreSQL DB instance keeps its log files. The default setting is 3 days (4,320 minutes), but you can set this value to anywhere from 1 day (1,440 minutes) to 7 days (10,080 minutes). Be sure that your RDS for PostgreSQL DB instance has sufficient storage to hold the log files for the period of time.
We recommend that you have your logs routinely published to Amazon CloudWatch Logs so that you can view and analyze system data long after the logs have been removed from your RDS for PostgreSQL DB instance. For more information, see Publishing PostgreSQL logs to Amazon CloudWatch Logs.
Parameters for logging in RDS for PostgreSQL - Amazon Relational Database Service
また、CloudWatch Logs Insightsなどでログに対して手軽に分析したい場合や、ログファイルの都度ダウンロードするのが面倒な場合もCloudWatch Logsにログを出力するモチベーションになります。
ログローテーションを10分など細かい頻度で行っていると、トラブルシューティングをする場面においてはログファイルを横断的に分析する必要があり、ダウンロードするだけでも手間です。
 やってみた 現在の状態の確認実際にAurora DBクラスターを停止→起動してもログが削除されないか確認しましょう。
Aurora PostgreSQLのドキュメントにはローカルストレージ上のログの保持についての記載がありませんでした。
Aurora PostgreSQLでも同様な動作をするのか確認してみます。
Aurora DBクラスター内に2つのDBインスタンスを用意しています。いずれもインスタンスクラスはdb.t4g.mediumです。
各DBインスタンスのログの状態は以下のとおりです。


 db.t4g.medium から db.r7g.largeに変更t系ではない場合、ログを保持することができるのか確認するために、database-1-instance-1のインスタンスクラスをdb.t4g.medium から db.r7g.largeに変更します。
db.r7g.largeに変更完了すると、error/postgresql.log.2025-01-07-0109やerror/postgresql.log.2025-01-07-0110といったログが削除されました。
なお、もう一台のDBインスタンスのログは削除されていません。WriterとReaderが入れ替わっていることから、フェイルオーバー時はログは削除されないようです。
 Aurora DBクラスターの停止それではAurora DBクラスターを一時的に停止します。
ステータスは停止中ですが、ログはまだ確認できます。
一時停止のリクエストをして、4分ほど待つとログを確認できなくなりました。
なお、Writer側ではまだログは確認できます。
10分ほど待つとWriterでもログの確認ができなくなりました。
 Aurora DBクラスターの起動それではAurora DBクラスターの起動を行います。
2台のDBインスタンスの起動が完了しました。
db.r7g.largeのDBインスタンスは停止したのが10:45ですが、error/postgresql.log.2025-01-07-0134と停止前のログが残っていることが分かります。
一方、t4g.mediumは最も古いログでerror/postgresql.log.2025-01-07-0158であり、error/postgresql.log.2025-01-07-0116など停止時10:54以前のログが残っていません。
このことから、Aurora PostgreSQLでも同様の条件でpostgres.logを保持すると言えます。
また、いずれのインスタンスクラスタイプでも一時停止中はログを表示できないことも分かります。
 db.r7g.large から db.r7g.xlargeに変更せっかくなのでインスタンスクラスのサイズを変更した際にもログを保持し続けるのか確認します。
db.r7g.large から db.r7g.xlargeに変更します。
変更完了後の状態を確認します。
インスタンスクラスの変更は11:18にリクエストを行いましたが、error/postgresql.log.2025-01-07-0134とインスタンスクラス変更前のログが残っていることが分かります。
このことからr系のインスタンスクラスにて、サイズを変更する場合はログを保持することが分かります。
 db.r7g.xlarge から db.r8g.largeに変更続いて別のインスタンスクラスタイプとサイズに変更した場合も、ログを保持し続けるのか確認します。
db.r7g.xlarge から db.r8g.largeに変更します。
変更完了後の状態を確認します。
インスタンスクラスタイプの変更は11:31にリクエストを行いましたが、error/postgresql.log.2025-01-07-0134とインスタンスクラスタイプ変更前のログが残っていることが分かります。
このことから、r系のインスタンスクラスから別のr系のインスタンスクラスに変更する場合もログを保持し続けることが分かります。
 db.r8g.large から db.t4g.mediumに変更t系のインスタンスクラスタイプに変更した場合も確認しましょう。
db.r8g.large から db.t4g.mediumに変更します。
変更完了後の状態を確認します。
今まで残っていたerror/postgresql.log.2025-01-07-0134ログが削除されたことが分かります。
このことから系のインスタンスクラスタイプからt系のインスタンスクラスタイプに変更した場合はログが削除されることが分かります。
 db.t4g.medium のDBインスタンスの再起動t系のインスタンスクラスタイプであっても再起動をする場合はどうでしょうか。
再起動を行います。
再起動をしたのは11:55ですが、error/postgresqllog.2025-01-07-0250と再起動前のログが残っています。
このことから、t系のインスタンスクラスタイプであっても再起動の場合はログを保持することが分かります。
 db.t4g.medium から Aurora Serverless v2に変更Aurora Serverless v2に変更した場合はどうでしょうか。
db.t4g.medium から Aurora Serverless v2に変更します。
変更完了後の状態を確認します。
変更のリクエストを行ったのは12:02で、以前あったerror/postgresql.log.2025-01-07-0250やerror/postgresql.log.2025-01-07-0251が削除されたことが分かります。
このことからt系のインスタンスクラスタイプからAurora Serverless v2に変更した場合はログが削除されることが分かります。
なお、もう片方のインスタンスのログは削除されていませんでした。
 Aurora Serverless v2を含むAurora DBクラスターを停止→起動Aurora Serverless v2を含むAurora DBクラスターを停止→起動した場合はどうでしょうか。
Aurora DBクラスターを停止します。
停止するとログが表示されなくなりました。
Aurora DBクラスターを起動させます。
起動完了後の状態を確認します。
起動のリクエストを行ったのは14:44で、停止前から存在していたerror/postgresql.log.2025-01-07-0311やerror/postgresql.log.2025-01-07-0313は残り続けていることが分かります。
このことからAurora Serverless v2でもログを保持し続けることが分かります。
 RDS for PostgreSQLの場合おまけです。Aurora PostgreSQLではなく、RDS for PostgreSQLの場合はt系のインスタンスクラスタイプでも、停止前のログを保持しています。
Auroraの場合はクラスターボリューム、ローカルストレージというストレージの概念がありましたが、RDSの場合は単純にEBSボリュームに保存されます。EBSボリュームは永続ストレージであるためログが削除されないと考えます。
 大事なログや分析に使いたいログはCloudWatch Logsに流そうAmazon Auroraではt系インスタンスクラスタイプを使用すると停止時にローカルストレージ内のログが削除されることを紹介しました。
コストはかかりますが、大事なログや分析に使いたいログはCloudWatch Logsに流しましょう。個人的にはData FirehoseやS3バケットに直接ログを流せられるようになるアップデートが来ることを待ち望んでいます。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!